home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0049 / 403.txt < prev    next >
Text File  |  1997-04-16  |  18KB  |  401 lines

  1. Info-Atari16 Digest   Tuesday, August 22, 1989   Volume 89 : Issue 403
  2.  
  3. This weeks Editor: Bill Westfield
  4.  
  5. Today's Topics:
  6.  
  7.                 How to find bad sectors on Hard Disk?
  8.                   Need Kind Soul to compile program!
  9.               Dallas Semi TIMECLOCK & Questions!  HELP!
  10.                       Re: Multitasking on the ST
  11.                       Re: Multitasking on the ST
  12.                   Re: Multitasking on the ST (Minix)
  13.                        Re: Apathy and Defeatism
  14.                             Cringely on TT
  15.                         How to do it propperly
  16.                upgrading SF354 to double-sided, how???
  17.  
  18. ----------------------------------------------------------------------
  19.  
  20. Date: 14 Aug 89 20:27:24 GMT
  21. From:
  22.  agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!jlong@ucbvax.Berkeley.EDU
  23.  (Jeffrey K. Long)
  24. Subject: How to find bad sectors on Hard Disk?
  25. To: info-atari16@score.stanford.edu
  26.  
  27. I have a 30 Meg hard disk that I home-brewed about a year ago.  Anyway, at
  28. the time I got the drive mech.  I lost the list of bad sectors which was
  29. taped to it.  I use ICD formatting utilities on the disk, but they never
  30. flag any defective sectors.  I seem to have a recurring problem whenever I
  31. get my disk just so full, that I feel like it must be a defective sector
  32. that is screwing up my programs whenever I try to load them.
  33.    Does anyone know of a program that does a good job of flagging bad
  34. sectors on a hard drive?   Any suggestions?  I have reformatted several
  35. times but the problem always seems to pop up latter!   Help!
  36.  
  37. =========================================================================
  38. |   Jeff Long              jlong@blackbird.afit.af.mil  (ARPA net)      |
  39. |                                                                       |
  40. |   humble (and getting humbler by the day) graduate student;           |
  41. |   The Air Force Institute of Technology  (what a great way of life??) |
  42.  
  43. ------------------------------
  44.  
  45. Date: 14 Aug 89 20:18:56 GMT
  46. From:
  47.  agate!helios.ee.lbl.gov!ncis.tis.llnl.gov!blackbird!jlong@ucbvax.Berkeley.EDU
  48.  (Jeffrey K. Long)
  49. Subject: Need Kind Soul to compile program!
  50. To: info-atari16@score.stanford.edu
  51.  
  52. Hi ,  I have been trying for several months (almost a year! really)
  53. to find a .dvi driver for my HP Deskjet which runs on a 1meg machine.
  54. The only one I have found requires PC-Ditto since it is a messy-dos
  55. program.  A while back I got JRD to compile some source code using his
  56. GCC port and with the exception of the requirement of more than 1meg of
  57. memory, it worked fine.  Well, I finally go hold of the source for the
  58. driver which processes the page in separate strips, so it will run on
  59. 1 meg and 512K machines.  But, the only C compiler I have is Laser-C and
  60. this source is the stuff from Utah that is written for about a zillion
  61. different C compilers, but none of which is a straightforward port using
  62. Laser-C.    Anyway, JRD was able to compile the earlier code up for me with
  63. little trouble, and this should be a similarly easy port using GCC (gosh I
  64. whish I had the extra memory so I could run GCC on these larger source code
  65. files!!)  I was wondering if there is anyone out there who, as a service to
  66. those of us with ST's and running LaTex and have a DeskJet, would be
  67. willing to try and port this source over to the ST.  It would be a very
  68. valuable service indeed!!   I would ask JRD to try again, but he has been
  69. so helpful in the past I hate to impose on his time anymore (not to mention
  70. the fact I erased my old mail from him and have lost his E-mail path :-)  )
  71. If anyone is willing to tackle this public service, please E-mail me a
  72. short note and we can discuss it further.    Thanks for reading this!!
  73.  
  74. =========================================================================
  75. |   Jeff Long              jlong@blackbird.afit.af.mil  (ARPA net)      |
  76. |                                                                       |
  77. |   humble (and getting humbler by the day) graduate student;           |
  78. |   The Air Force Institute of Technology  (what a great way of life??) |
  79.  
  80. ------------------------------
  81.  
  82. Date: 14 Aug 89 21:32:43 GMT
  83. From: dino!sharkey!bnlux0!max.bnl.gov!atc@uunet.uu.net  (Andrew Como)
  84. Subject: Dallas Semi TIMECLOCK & Questions!  HELP!
  85. To: info-atari16@score.stanford.edu
  86.  
  87. Hello world!  Thanks for all the replies to my timeclock question.
  88.  
  89.     A few people pointed me to the Dallas Semi conductor clock/socket
  90. chip and said it was running on their Atari ST.
  91.  
  92.     I was given some software to run the clock that was written by some
  93. now-defunct software house in Calif (the name escapes me).  The software
  94. doesn't seem to work with the clock inserted in any of the ST's rom positions.
  95.  
  96.     I figure I'll write my own driver for the thing however it states the
  97. clock uses address line A0 as part of the handshake.  According to my ATARI
  98. ST INTERNALS book by Abacus the 68000 in the ST can't access A0!
  99.  
  100.     Has anyone sucessfully written software to run the clock chip on the
  101. 1040 ST?
  102.  
  103.     Also the Dallas Semi chip is rather bulky in the 1040 ST ..basically
  104. I'm gonna have to cut the power supply housing to make it fit.  Does anyone
  105. know of a cartridge timeclock?
  106.  
  107. ------------------------------
  108.  
  109. Date: 14 Aug 89 20:50:12 GMT
  110. From: cbmvax!daveh@uunet.uu.net  (Dave Haynie)
  111. Subject: Re: Multitasking on the ST
  112. To: info-atari16@score.stanford.edu
  113.  
  114. in article <29201@pbhya.PacBell.COM>, dbsuther@PacBell.COM (Daniel B. Suthers)
  115.  says:
  116.  
  117. > After reading this a question popped into my head.  If you are downloading in
  118. > the back ground (it seems the most popular multi-task task) and running a
  119. > action game in the foreground,  do you set the download process to the
  120. > highest priority to avoid losing data or do you just put up with longer
  121. > download times and connect times so your joy-stick will be responsive?
  122.  
  123. Assuming your connection won't time out on you, and all your actual byte
  124. grabbing is interrupt or DMA driven (as on the Amiga), it's pretty much a matter
  125. of personal choice.  Or looking at it another way, at least when talking to a
  126. commercial network, you'll pay for a higher game score with longer connect
  127. times.
  128.  
  129. It's probably not that simple, though.  In many video games, the game itself
  130. is taking most of the CPU time, at least on a 68000 processor.  So if your
  131. video game is at a priority higher than that of your download, you may starve
  132. the XMODEM or Kermit protocol program.  To be safe, I'd keep the download at
  133. the same or greater priority than that of the game.  Though on 68020 or 68030
  134. Amigas, you rarely run into that kind of process starvation.
  135.  
  136. > While I'm at it...
  137. > What is a "ray trace" that most amiga users seem to want to generate them, and
  138. > are willing to wait 2 or 3 days for the output???  The ray traces I've done
  139. > have always completed over-night, and that's longer than I wish to wait for
  140. > a pretty drawing.
  141.  
  142. Lots of Amiga folks are doing pretty serious ray tracing.  Part of the limits of
  143. what you're going to be tracing are based on what you have available to enter
  144. the image in the first place.  Tools on the Amiga like Byte-by-Byte's Sculpt-
  145. Animate 4D allow some pretty serious drawings to be entered.  It's not only
  146. a timing issue, either -- I have two friend heavily into ray tracing.  One is
  147. currently hitting memory limits on a 17 megabyte system I've set up here at
  148. Commodore, the other already has some images that can't be rendered on a 25
  149. megabyte system.  These certainly aren't typical users, but even for smaller
  150. ray traces, what finishes in 20 minutes on a 68030 system might take 25-100
  151. times longer on a 68000 system.
  152.  
  153. > Dan Suthers, Analyst, Pacific Bell
  154. --
  155. Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
  156.    uunet|pyramid|rutgers!cbmvax!daveh      PLINK: D-DAVE H     BIX: hazy
  157.            Be careful what you wish for -- you just might get it
  158.  
  159. ------------------------------
  160.  
  161. Date: 14 Aug 89 23:00:05 GMT
  162. From: ncrlnk!ncr-sd!tw-rnd!johnl@uunet.uu.net  (John Lindwall)
  163. Subject: Re: Multitasking on the ST
  164. To: info-atari16@score.stanford.edu
  165.  
  166. In article <1071@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
  167. >In article <482@tw-rnd.SanDiego.NCR.COM> johnl@tw-rnd.SanDiego.NCR.COM ()
  168.  writes:
  169. >|In article <1066@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
  170. >   []
  171. >|>Why should memory protection be a hotter item when parallel processes
  172. >|>are involved?
  173. >|
  174. >|Because of the potential for a single user program to cause the termination
  175. >|of all the processes in the system.
  176. >
  177. >This is equally well possible in the current 'one-process-running-at-a-time'
  178. >scheme. Note that there are already accessory-based editors, batch
  179. >modem transfer programs, TSR print spoolers for the ST right now.
  180. >
  181.  
  182. This point is well taken, but does not negate the point that process protection
  183. is desirable (in my mind).
  184.  
  185. >| [My (John Lindwall's) example of a single process crashing the machine]
  186. >
  187. >I think you'll need a bit more than just an MMU for a secure system.
  188. >S'pose your nasty process alters some system vector (applying patch 271
  189. >to SAFEDOS). A pity that the last bug was not yet removed... My point
  190. >is, that a MMU is a probably undispensable ingredient IN AN OTHERWISE
  191. >EXCELLENT SYSTEM.  That safe system (which undoubtedly will have a
  192. >notion of privileges, users) is what you should start with in the first
  193. >place.
  194. >
  195.  
  196. An MMU can protect pages of memory that the system considers special.  The
  197. system vectors could be marked as un-writable by user level processes. An
  198. attempt to modify the protected pages could be trapped and prevented.
  199.  
  200. I agree that the capabilities of an MMU are best utilized when designed into a
  201. system as opposed to grafted in as an afterthought.  Current users of
  202. Commodore's 68020/68030 boards have an MMU in the system which has minimal
  203. benefit to the system, because AmigaDOS was not designed to support an MMU.
  204. In fact the only use I see for it (in the Amiga at present) is in copying the
  205. OS ROM into fast ram for a speed gain.  True use of the MMU comes when running
  206. an OS designed to use it (like Unix when that becomes available).
  207.  
  208. I am using the Amiga as an example here not because I believe it is the ULTIMATE
  209. SYSTEM that Atari should emulate.  I feel ST users and developers can
  210. benefit from examining the problems and shortcomings that the Amiga is seeing
  211. now that MMU's are being phased in as standard equipment.
  212.  
  213. >B.T.W. what do you do when a thunderstorm is coming up, but your
  214. >raytracer has yet to finish its last hour of calculations? Use a TMU :-) ?
  215. >
  216.  
  217. Well, here in Sunny California (tm) we don't get many of those! :) :) :)
  218.  
  219. >|I'm all for system robustness for ANY system.  My point is that when you
  220. >|introduce multitasking, memory protection is more important due to the
  221. >|potential to disrupt other processes.
  222. >
  223. >I heard this one before and I still won't believe it, unless a proper
  224. >argument is given.
  225. >
  226.  
  227. So I assume (if you were using a multi-tasking system) that you would prefer
  228. NOT to have process protection?  I do not see the logic in this.
  229.  
  230. >|>[about VM]
  231. >|
  232. >|Sounds Good!  But now you're wandering into the area of virtual memory and
  233. >|that's not what our original discussion was about.  Thanks for the reply.
  234. >
  235. >You bought an MMU but you don't want VM? Gee, that would be the first
  236. >reason I would buy an MMU for (and not for protection). As long as the
  237. >filesystems used are single-user, not write protectable, I don't care
  238. >much for safe core.
  239. >
  240.  
  241. Yes, VM is nice.  In my day-to-day Amiga experience I do not run out of memory
  242. much.  I DO experience agonizing crashes which kill all my processes.  From
  243. this experience I developed the priority of process protection being more
  244. important.  If VM were available, I'm sure I would enjoy it and make use of it.
  245.  
  246. Thank you for this enjoyable discussion.  I hope it can continue on the
  247. amiable and informative level that has been maintained all along.  Looking
  248. forward to your reply.
  249.  
  250. ----------------------------------------------------------------------
  251. John Lindwall                            johnl@tw-rnd.SanDiego.NCR.COM
  252.            "Above opinions are my own, not my employer's"
  253.    Health is merely the slowest possible rate at which one can die.
  254.  
  255. --
  256. ----------------------------------------------------------------------
  257. John Lindwall                            johnl@tw-rnd.SanDiego.NCR.COM
  258.            "Above opinions are my own, not my employer's"
  259.    Health is merely the slowest possible rate at which one can die.
  260.  
  261. ------------------------------
  262.  
  263. Date: 14 Aug 89 15:10:30 GMT
  264. From: polygen!jerry@bu-cs.bu.edu  (Jerry Shekhel)
  265. Subject: Re: Multitasking on the ST (Minix)
  266. To: info-atari16@score.stanford.edu
  267.  
  268. In article (Dzung Hoang) writes:
  269. >In article (DAVID MEGGINSON) writes:
  270. >>
  271. >>From what I've heard, Minix is very restrictive with memory.  Each
  272. >>program is allowed a maximum of 64k, and there is not VM paging.  A cute
  273. >>toy, but useless for anything but learning.
  274. >>
  275. >    Minix for the IBM-PC's are restricted to 64K due to the PC's
  276. >architecture.  The 68000 in the ST does not have any such restriction so it
  277. >can run programs larger than 64K.  It is not "useless for anything but
  278. >learning."  Post a message in comp.os.minix and you'll see what I mean.
  279. >
  280. >    I used to have an ST but now own an AT compatible.  I wish I still have
  281. >the ST (and a big hard drive) to run minix.
  282. >
  283.  
  284. I've also had both the ST and the PC versions of Minix.  The PC version's
  285. limitation is not 64K.  A program may have 64K of code AND 64K of stack/data,
  286. for a total program size of 128K.
  287.  
  288. This limitation is used for two reasons: it is reasonable for a teaching OS
  289. and most Minix utilities (MOST -- no 16-bit compress!), and it makes forking
  290. EXTREMELY fast and simple.
  291.  
  292. Sure, you can run monstrous GNU stuff on ST Minix -- that is its strength --
  293. unlimited program size.  But try to run anything that forks a lot, like
  294. extracting programs from a shell archive, and you'll see the ST slow down
  295. to an unbelievable crawl, while my 8MHz AT zips along on the same job.
  296. And worse, try to run a program which forks and does not immediately exec(),
  297. and you'll be begging for an MMU!
  298.  
  299. But just like the above poster, I sure wish I had a big hard drive for my
  300. ST Minix!
  301. ---
  302. +--------------------+-----------------------+-------------------------------+
  303. |                    |  Polygen Corporation  |           UUCP:               |
  304. |  Jerry J. Shekhel  |   Waltham, MA 02254   |  princeton, mit-eddie,       |
  305. |                    |    (617) 890-2888     |  buita, sunne!polygen!jerry  |
  306.  
  307. ------------------------------
  308.  
  309. Date: 14 Aug 89 22:58:46 GMT
  310. From:
  311.  cs.utexas.edu!csd4.csd.uwm.edu!srcsip!tcnet!nic.MR.NET!ns!logajan@tut.cis.ohio-
  312. state.edu  (John Logajan)
  313. Subject: Re: Apathy and Defeatism
  314. To: info-atari16@score.stanford.edu
  315.  
  316. Xorg@cup.portal.com (Peter Ted Szymonik) writes:
  317. > Atari's strategy HAS also worked by the way - financially the company is
  318. > very strong and solid and 400 on the Fortune 500 list - far from an
  319. > easy achievement for a compnay that appeared a mere four years ago!
  320.  
  321. Atari is also number 91 as far as all US companies involved in electronic
  322. equipment manufacture (not just computers!)  Atari is a relatively large
  323. (net income wise) company.
  324.  
  325. --
  326. - John M. Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428  -
  327. - logajan@ns.network.com / ...rutgers!umn-cs!ns!logajan / john@logajan.mn.org -
  328.  
  329. ------------------------------
  330.  
  331. Date: 14 Aug 89 21:47:36 GMT
  332. From: att!chinet!saj@ucbvax.Berkeley.EDU  (Stephen Jacobs)
  333. Subject: Cringely on TT
  334. To: info-atari16@score.stanford.edu
  335.  
  336. The 'Cringely' column in Infoworld today said that the TT will be officially
  337. announced August 25.  He mentions some reasonable prices and specs.  By
  338. experience, he's about as (in)accurate as most rumor mongers.  So keep your
  339. fingers crossed, but remember the source, too.
  340.    Other than that, I'd still be glad to hear about an ST or Mega delivered
  341. into US retail channels with TOS 1.4.  Any sightings yet?
  342.    Another thing I'd be interested in is a connoiseur's opinion of HDX 3.1,
  343. or whatever the new disk software is properly referred to as.  Good and bad
  344. points.
  345.                                       Steve J.
  346.  
  347. ------------------------------
  348.  
  349. Date: 13 Aug 89 23:44:48 GMT
  350. From: ubc-cs!alberta!calgary!cpsc!schock@beaver.cs.washington.edu  (Craig
  351.  Schock)
  352. Subject: How to do it propperly
  353. To: info-atari16@score.stanford.edu
  354.  
  355.  Hi,
  356.  
  357.     For the last while I've been trying to find out how to use the
  358. LINE A (Copy Raster form ) Opcode $A00E propperly.  Does anyone know the
  359. correct procedure for setting up and making a call to $A00E.  All the docs
  360. I've recieved over the last 6 months have all been kludgy and all seem to
  361. contradict one another.  I've gotten something to work, but it's pretty
  362. flakey.  Any help on this matter would be greatly appreciated!
  363.  
  364. Thanks in Advance
  365.  
  366. Craig Schock
  367. Dept. of Computer Science
  368. University of Calgary.
  369.  
  370. ------------------------------
  371.  
  372. Date: 15 Aug 89 03:46:31 GMT
  373. From: usc!ginosko!rex!hoang@bloom-beacon.mit.edu  (Dzung Hoang)
  374. Subject: upgrading SF354 to double-sided, how???
  375. To: info-atari16@score.stanford.edu
  376.  
  377.     I am attempting to upgrade a SF354 disk drive to a double sided drive
  378. by replacing the mechanism with an NEC FD1035 drive.  I thought that the
  379. procedure would be simple until I saw that the connectors on the two
  380. drive mechanisms are not the same.  The SF354 has a 14-pin single-row
  381. connector while the NEC has a 34-pin two-row connector.  I have read that
  382. this upgrade is a simple matter.
  383.     Could it be that my SF354 is a different version?
  384.  
  385.     Has anyone attempted the same feat successfully.  If so, I would
  386. appreciate hearing how you did it.
  387.  
  388. Dzung Hoang
  389. --
  390. -----------------------------------------------------------------------------
  391. hoang@comus.cs.tulane.edu                   hoang@rex.cs.tulane.edu
  392. hoang@comus.UUCP                            hoang@rex.UUCP
  393. tulane!comus!hoang                          tulane!rex!hoang
  394.  
  395. ------------------------------
  396.  
  397. End of Info-Atari16 Digest
  398. **************************
  399. -------
  400.  
  401. ə